Removing the possibility to ignore an exception at the Eiffel level

by Jocelyn-Fiat (modified: 2013 Sep 26)

Do you know EXCEPTIONS and the associated ISE_EXCEPTION_MANAGER provides a way to ignore exception (apart the Call on Void target exception, i.e VOID_TARGET), either by code or by exception type.

See

{EXCEPTIONS}.ignore (code: INTEGER)
{ISE_EXCEPTION_MANAGER}.ignore (a_exception: TYPE [detachable EXCEPTION])

And the reverse operations `catch

The default is to catch any exception.

As far as we know, at Eiffel Software, this facility is not used by any users and we are planning to remove this possibility in future releases.Thus in the upcoming release, the related routines would be marked as obsolete, and then they will be removed in future releases.

This would be mainly to simplify the related implementation, and in addition this would benefit Void-safety code.Indeed when one start designing a project in void-safe mode, you don't want to create fake implementation just to satisfy the attached status for the result of a function, hopefully the compiler interprets "False" post-condition to stop checking for attached status. This behavior is currently used with {EXCEPTIONS}.die (a_code) that has a "False" post-condition, and this is correct, because the execution of die' will exit the execution, and this no code can be reached after (following code is {EXCEPTIONS}.die')

die (code: INTEGER) -- Terminate execution with exit status `code', -- without triggering an exception. external "C use %"eif_except.h%"" alias "esdie" ensure False end

For now, it is not possible to add such "False" post-condition to {EXCEPTION}.raise (or related) because nothing ensures that the related exception may not be ignored, and thus, following instruction can be reached.

An example is typically

class TEAM feature -- Access members: LIST [PERSON] do end end

The compiler will complain about such code since `members' is attached, and no Result is set.A way to continue the design in void-safe more is to use exceptions for instance like following code

class TEAM feature -- Access members: LIST [PERSON] do io.error.put_string ("TEAM.members is not yet implemented%N") (create {EXCEPTIONS}).die (-1) end end

After the call on `die', the compiler stops checking void-safety on the rest of the body, since the following code will never be reached.In this case, even if the code does not return an attached list, it does not matter since at run-time the execution will die right away.

Now, it would be convenient to raise an exception instead of exiting the execution, so it would be great to be able to do

class TEAM feature -- Access members: LIST [PERSON] do (create {EXCEPTIONS}).raise ("Not yet implemented") end end

This is the main reason we are investigating the removal of this possibility to ignore exception.Indeed if it is not possible anymore to ignore exception at runtime, then the compiler knows for sure that the execution of members' will be interrupted by an exception, and then no caller of members' will actually use the result since an exception will be raised and be catch somewhere. (Note that a custom exception could also be used for that purpose with (create {NOT_YET_IMPLEMENTED_EXCEPTION}).raise).

Removing the possibility to ignore exception will have the big advantage to allow designing void-safe interfaces without having to provide fake implementation (which is not always possible).

As we don't see any scenario that would require to ignore exception via ISE_EXCEPTION_MANAGER.ignore (...) (or similar), it seems pertinent to remove it for the following points:- simpler code for exception implementation- allow painless void-safe interface design

However before going that way, we would like to know if any one is currently using this functionality in an existing project?

Please comment about this if you feel we should keep possible to ignore some type of exception.

Comments

Bernd Schoeller (10 years ago 27/9/2013)
Thumbs up from me. Anything that simplifies the language and allows the compiler to be more powerful is good.
Howard Thomson (10 years ago 27/9/2013)
Alternate processing of Exceptions

Hi Jocelyn,

I agree that the proposal to ignore exceptions altogether [other than call on Void target] has considerable merit. It is not a facility that I use, or have seen in any of the Eiffel code that I have so far read.

I think the option to ignore floating point exceptions should probably be retained.

I would also suggest that there be a means of adapting the type of exception class created on exception for all exception types, with a revert option.

Not a well-though-out suggestion, but a possible alternative to just ignoring exception events ...

Regards,

Howard
Olivier Ligot (10 years ago 27/9/2013)
EWF and IO_FAILURE

Hi,

We use the Exceptions handling tool (http://docs.eiffel.com/book/eiffelstudio/exceptions-handling-tool) to ignore the IO_FAILURE exception. The IO_FAILURE exception occurs when we use the EiffelWebFramework library (https://github.com/EiffelWebFramework/EWF) and a client aborts a pending request. EWF will then try to write on the socket but the client is not there anymore. Here is a excerpt of the backtrace:

Class / Object Routine Nature of exception Effect ------------------------------------------------------------------------------- TCP_STREAM_SOCKET c_put_stream Broken pipe: <00007F3F95A71438> (From SOCKET) I/O error. Fail ------------------------------------------------------------------------------- TCP_STREAM_SOCKET c_put_stream <00007F3F95A71438> (From SOCKET) Routine failure. Fail ------------------------------------------------------------------------------- TCP_STREAM_SOCKET put_managed_pointer @5 <00007F3F95A71438> (From SOCKET) Routine failure. Fail ------------------------------------------------------------------------------- TCP_STREAM_SOCKET put_readable_string_8 @2 <00007F3F95A71438> Routine failure. Fail ------------------------------------------------------------------------------- WGI_NINO_OUTPUT_STREAM put_string @3 <00007F3F95A77888> Routine failure. Fail ------------------------------------------------------------------------------- WGI_NINO_OUTPUT_STREAM put_crlf @1 <00007F3F95A77888> (From WGI_OUTPUT_STREAM) Routine failure. Fail ------------------------------------------------------------------------------- WGI_NINO_OUTPUT_STREAM put_header_line @2 <00007F3F95A77888> (From WGI_OUTPUT_STREAM) Routine failure. Fail ------------------------------------------------------------------------------- WGI_NINO_OUTPUT_STREAM put_status_line @12 <00007F3F95A77888> Routine failure. Fail ------------------------------------------------------------------------------- WGI_NINO_RESPONSE_STREAM set_status_code @6 <00007F3F95A778A8> (From WGI_RESPONSE_STREAM) Routine failure. Fail ------------------------------------------------------------------------------- WSF_WGI_DELAYED_HEADER_RESPONSE set_status_code @4 <00007F3F95A77988> (From WGI_FILTER_RESPONSE) Routine failure. Fail ------------------------------------------------------------------------------- WSF_RESPONSE process_header @3 <00007F3F95A779B8> Routine failure. Fail ------------------------------------------------------------------------------- WSF_WGI_DELAYED_HEADER_RESPONSE process_header @3 <00007F3F95A77988> Routine failure. Fail ------------------------------------------------------------------------------- WSF_WGI_DELAYED_HEADER_RESPONSE put_string @2 <00007F3F95A77988> Routine failure. Fail ------------------------------------------------------------------------------- WSF_RESPONSE put_string @2
- Jocelyn-Fiat (10 years ago 27/9/2013)
  What you describe is only for the debugger
  
  Indeed with the debugger we can ignore the exception, but this only means that the debugger will not stop, but what I describe in the post is really at the run-time level, where we can prevent the execution to catch specific exception in rescue clause for instance.
  
  So just to precise, the debugger will still be able to ignore any exception (i.e does not interrupt the execution).
  - Olivier Ligot (10 years ago 28/9/2013)
    Ok, good to know.